Replicating User Profiles Between Sites (With or Without DFS) – Why it Should be Avoided

This article is part of Helge’s Profile Toolkit, a set of posts explaining the knowledge and tools required to tame Windows user profiles.

Roaming user profiles seems like such a good idea at first, but it causes a myriad of problems in practice. One of these problems stems from the fact that the master copy of each profile is stored on a central file share. That file share needs to be accessible over a fast connection from all machines a user is logging on to, or logons tend to become very slow. This proximity requirement is easy to meet if only one site is involved, but what if users roam between different locations, or if terminal servers are distributed across several data centers? Unfortunately, there is no easy answer to this question.

Can DFS Replication be the Answer?

It looks like replication is the obvious solution. If you have users alternately working in multiple sites, replicate their profiles between those sites and – bingo – the problem is solved. No matter where they log on from, there will always be a copy of their profile nearby.

Put differently, why not simply copy the profiles to all sites users are working in? Windows has a very nice technology included called DFS-R (distributed file system – replication), that looks ideally suited for the task. Alas, it is not.

The basic problem is that replication takes time. What happens if user Ben changes his profile in site A and logs off, only to immediately log on to some machine in site B and make some changes there, too? In such a scenario you have two differing “master” copies of one profile, a situation no known replication software can deal with efficiently. DFS-R, if used here, would merge both versions of the profile, since it is a two-way replication system by design. It is unlikely that Ben would be happy with the resulting merged version of his profiles.

DFS-R is not the right technology for the task of multi-master user profile replication. Microsoft is well aware of this “limitation” (which really is none since DFS was not designed for replicating profiles, as far as I know) and describes it in a document on its Technet site. Or so I remember from a while back. Interestingly, I cannot find that reference any more, not even with Bing. So either I remember incorrectly (I do not think so), the document was removed (maybe) or I am too stupid to dig it up (possible). Whatever the reason, I found out the following: there is no single (findable) document on the internet that states with credible authority if you can or cannot use DFS-R to replicate user profiles between sites. Why? I have no clue. But, if you can extend even the slightest amount of trust towards this blog, then do not do it, unless you can get Microsoft to guarantee support for your setup.

What Can You Do With DFS-R and User Profiles?

Not much. First you would have to ensure that each profile is only accessed from a single location at a time. That alone is difficult with DFS-R, since it is by nature a two-way mechanism. Then the latency problem would arise. Before a profile earlier used in site A can be used in site B (instead!), replication of that profile from site A to site B must have completed. It would not do to have only half the updates from site A in site B when a user logs on in site B. To my knowledge, DFS-R offers no mechanism whatsoever to guarantee atomicity at a (profile) folder level, so that either everything has replicated (which you need) or nothing (which you do not want).

What About Other Replication Technologies?

Every large storage vendor has a replication solution that either synchronously or asynchronously (but with low latency) replicates between storage systems or even data centers. The main benefit of such systems (example: Hitachi TrueCopy) with regards to user profiles is the negligible or even non-existent latency. But even with such highly priced technologies you are stuck with the problems of guaranteeing there only ever is a single master copy of each profile, and ensuring atomicity at a profile level. These constrains make even high-end replication mechanisms unsuitable for the replication of user profiles between multiple alternately or concurrently used sites.

Disaster Recovery, Anyone?

Most larger companies are very concerned about potential disasters involving entire data centers and how to quickly recover from such events. Disaster recovery is the only application of replication I know of that makes sense (again, this applies to user profiles only). In order to have a readily available backup copy of your profiles, use a low-latency replication system (not DFS-R) to continuously synchronize the profiles from the primary to a secondary data center. In the event of a major failure in the primary data center, switch everything over to the secondary data center. From then on, only use the secondary systems. Once the primary data center is operational again, demote the former primary site to a secondary site and synchronize the other way round. Or synchronize from secondary to primary and then switch back over to the main site.

Centralized Backup it is

According to an article in Microsoft’s “Ask the Directory Services Team” blog and KB2533009 that appeared after I wrote this article, replicating user profiles with DFS-R is supported in one scenario only: bringing in user profiles from branch offices to the headquarter for backup. That is about the only sensible use case I can think of, too. Please note that in this scenario the profiles are never used in the headquarter. Remember: One profile may be used in one location only.

Thanks to commenter Michael for bringing up this topic.